第3章 需求分析

软件工程基本原理第一条：用分阶段的生命周期计划严格管理。

软件定义时期是软件周期的第一个时期，需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么？”这个问题。

在需求分析阶段，需要确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。

尽管目前有许多不同的用于需求分析的结构化分析方法，但是，所有这些分析方法都遵守下述准则：

  1. 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。
  2. 必须定义软件应完成的功能，这条准则要求建立功能模型。
  3. 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。
  4. 必须对描述信息、功能和行为模型进行分解，用层次的方式展示细节。

3.1 需求分析的任务

  1. 确定对系统的综合要求
    1. 功能需求
    2. 性能需求
    3. 可靠性和可用性需求
    4. 出错处理需求
    5. 接口需求
    6. 约束
    7. 逆向需求
    8. 将来可能提出的需求
  2. 分析系统的数据要求
    1. 建立数据模型——ER图
    2. 描绘数据结构——层次方框图和Warnier图
    3. 数据结构规范化
  3. 导出系统的逻辑模型：综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
  4. 修正系统的开发计划：根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。

3.2 与用户沟通获取需求的方法

访谈

  1. 正式访谈：系统分析员将提出一些事先准备好的具体问题。

  2. 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。

  3. 调查表：调查大量人员的意见，经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。

  4. 情景分析技术：对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。

    情景分析技术的用处：

    1. 能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。
    2. 能保证用户在需求分析过程中始终扮演一个积极主动的角色。让用户起积极主动的作用对需求分析工作获得成功是至关重要的。

面向数据流自顶向下求精

结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

  1. 分析追踪数据流图

    通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级，通常从数据流图的输出端着手分析，因为系统的基本功能就是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。

  2. 用户复查

    必须请用户对上述分析过程中得出的结果仔细地复查。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。

**随着分析过程的进展，经过问题和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。 **

img

简易的应用规格说明技术

简易的应用规格说明技术是一种面向团队的需求收集法。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。

分析需求的典型过程如下：

  1. 初步访谈，准备会议

    首先进行初步的访谈，初步确定待解决的问题的范围和解决方案。

    然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举协调人。

  2. 会前审查需求，确定列表

    要求每位与会者在开会的前几天认真审查产品需求，并且列出对象、操作这些对象或与这些对象交互的服务、约束条件和性能标准。

  3. 会上讨论列表，创建组合列表

    每位与会者展示列表供大家讨论。大家共同创建一张组合列表。由协调人主持讨论这些列表。

  4. 分组制定小型规格说明

    与会者分成更小的小组，为每张列表中的项目制定小型规格说明。每个小组都向全体与会者展示他们制定的小型规格说明，供大家讨论。

  5. 制定确认标准，起草需求规格说明书

    每个与会者都制定出产品的一整套确认标准，并提交会议讨论，以创建出意见一致的确认标准。

    最后，起草完整的软件需求规格说明书。

简易的应用规格说明技术的优点：

  1. 开发者与用户不分彼此，齐心协力，密切合作；

  2. 即时讨论并求精；

  3. 有能导出规格说明的具体步骤。

快速建立软件原型

特性：

  1. 快速。快速原型的目的是尽快向用户提供一个可在计算机上运行的目的系统的模型，因此，原型的某些缺陷是可以忽略的。
  2. 容易修改。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户需求。如果修改耗时过多，势必延误软件开发时间。

为了快速地构建和修改原型，通常使用下述3种方法和工具：

  1. 第四代技术（4GL）

    第四代技术包括众多数据库查询（如SQL）和报表语言（如ADF）、程序和应用系统生成器（如Power Builder和Oracle的应用开发环境）以及其他非常高级的非过程语言。

    第四代技术使得软件工程师能够快速地生成可执行的代码，它们是较理想的快速原型工具。

    第四代技术特点：
简单易学，用户界面良好，面向问题、非过程化程度高，用户只需告知系统做什么，而无需说明怎么做。用4GL编程使用的代码量较少，并可成数量级地提高软件生产率。

程序设计语言划代：
1GL是汇编语言；
2GL是高级程序设计语言，如FORTRAN，ALGOL，BASIC，LISP等；
3GL是增强性的高级程序设计语言，如PASCAL，ALGOL68，FORTRAN77等；
4GL是按计算机科学理论指导设计出来的结构化语言，如ADA，MODULA－2，SMALLTALK－80，JAVA，VB，VC，VF等。

  2. 可重用的软件构件

    使用一组已有的软件构件(也称为组件)来装配(而不是从头构造)原型。

    软件构件可以是数据结构(或数据库)，或软件体系结构构件(即程序)，或过程构件(即模块)。

  3. 形式化规格说明和原型环境

    非形式化方法：自然语言描述

    半形式化方法：数据流图或实体-联系图

    形式化方法：基于数学的技术

3.3 分析建模与规格说明

分析建模

**模型：**就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。

**结构化分析过程：**实质上是一种创建模型的活动。系统分析员从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。

需求分析过程应该建立3种模型，分别是：数据模型、功能模型、行为模型。

img

**数据字典：**是分析模型的核心，它描述软件使用或产生的所有数据对象。

**实体-联系图：**描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。

**数据流图：**描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础。

**状态转换图(简称为状态图)：**指明了作为外部事件结果的系统行为。为此，状态转换图描绘了系统的各种行为模式(称为“状态”)和在不同状态间转换的方式。状态转换图是行为建模的基础。

软件需求规格说明

通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。

我国定义了GB856D-1988国家标准，给出了需求规格说明的内容框架：

img

3.4 实体-联系图

概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，且与在软件系统中的实现方法无关。

数据模型中包含3种相互关联的信息：

  1. 数据对象

    数据对象：是对软件必须理解的复合信息的抽象。复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象。

    数据对象可以是外部实体、事物、行为、事件、角色、单位、地点或结构等。

    数据对象彼此间是有关联的。 数据对象只封装了数据而没有对施加于数据上的操作的引用。

  2. 数据对象的属性

    属性：定义了数据对象的性质。必须把一个或多个属性定义为“标识符”。

    根据对问题的理解来确定特定数据对象的合适的属性。

  3. 数据对象彼此间相互连接的关系

    数据对象彼此之间相互连接的方式称为联系，也称为关系。

    联系可分为以下3种类型：

    1. 一对一联系(1∶1)

    2. 一对多联系(1∶N)

    3. 多对多联系(M∶N)

    联系也可能有属性。

实体-联系图简称ER图，ER图描绘的数据模型称为ER模型。

ER图中包含

​ 实体(即数据对象)，用矩形框表示；

​ 关系，用连接相关实体的菱形框表示；

​ 属性，用椭圆形或圆角矩形表示，并用直线把实体(或关系)与其属性连接起来。

ER图的优点

  1. 比较接近人的习惯思维方式；

  2. 用简单的图形符号表达系统分析员对问题域的理解，用户也容易理解，可以作为用户与分析员之间有效的交流工具。

3.5 数据规范化

软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。

通常用“范式(normal forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。

范式级别越高，存储同样数据需要分解成更多张表，因此，“存储自身”过程越复杂。

随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。

范式级别提高则需要访问的表增多，因此性能(速度)将下降。

第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。

第二范式：满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。

第三范式：符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。

3.6 状态转换图

状态转换图：通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。

**状态：**是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。

状态主要有：

  1. 初态(即初始状态)，只能有1个

  2. 终态(即最终状态)，可以有0至多个

  3. 中间状态

状态图分类：

  1. 表示系统循环运行过程，通常不关心循环是怎样启动的。

  2. 表示系统单程生命期，需要标明初始状态和最终状态。

事件：是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。

符号：

​ **初态：**用实心圆表示；

​ **终态：**用一对同心圆(内圆为实心圆)表示；

​ **中间状态：**用圆角矩形表示，分成上、中、下3部分。

  • 上面部分-----为状态的名称；

  • 中间部分-----为状态变量的名字和值；

  • 下面部分-----是活动表。

**带箭头的连线：**称为状态转换，箭头指明了转换方向。

image-20200324155347949

活动表的语法格式：

事件名(参数表)/动作表达式

“事件名”可以是任何事件的名称。

常用的3种标准事件：

  1. entry事件指定进入该状态的动作；

  2. exit事件指定退出该状态的动作；

  3. do事件则指定在该状态下的动作。

需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。

事件表达式的语法：

事件说明［守卫条件］／动作表达式

事件说明的语法为：事件名(参数表)。

守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。

动作表达式是一个过程表达式，当状态转换开始时执行该表达式。

3.7 其他图形工具

层次方框图：

​ 用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。

Warnier图：

和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。

特点：用Warnier图可以表明信息的逻辑组织，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。

IPO图：

IPO图是输入、处理、输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。

基本形式：是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。

改进的IPO图：这种图中包含某些附加的信息，在软件设计过程中将比原始的IPO图更有用。

用途：在需求分析阶段可以使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。

3.8 验证软件需求

从哪些方面验证软件需求的正确性：

  1. **一致性：**所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
  2. **完整性：**需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
  3. **现实性：**指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
  4. **有效性：**必须证明需求是正确有效的，确实能解决用户面对的问题。

验证软件需求的方法

  1. 验证需求的一致性
    1. 软件系统规格说明书非形式化：人工技术审查
    2. 软件系统规格说明书形式化：软件工具验证需求——形式化的描述软件需求的方法
  2. 验证需求的现实性：仿真或性能模拟技术
  3. 验证需求的完整性和有效性：开发原型系统

用于需求分析的软件工具

软件工具应该满足下列要求：

  1. 必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；

  2. 使用这个软件工具能够导出详细的文档；

  3. 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；

  4. 使用这个软件工具之后，应该能够改进通信状况。